Subject: APPN DLUR Version 1.0 CP draft document (DLUR-5) available

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Wed, 15 Jun 94 16:53:38 EDT

The DLUR Version 1.0 architecture document has been updated and is
available by anonymous FTP to networking.cary.ibm.com (also known as
ibmstandards.cary.ibm.com) under the name of
pub/standards/aiw/dlur/dlur5.psbin - the file is a PostScript file, but
treat it as binary when you get it and print it.  There are also
compressed versions of the file (pub/standards/aiw/dlur/dlur5.zipbin and
pub/standards/aiw/dlur/dlur5.exebin) as well as a BookManager version
(pub/standards/aiw/dlur/dlur5.bookbin).

The items added in DLUR-5 are:

** 1) updated DLUS processing of DLUR ACTPU Indicator in XID3

      Currently the DLUS will not send an ACTPU over a TG to an
      adjacent DLUR when it receives an XID3 with the ACTPU Suppression
      Indicator reset and the DLUR ACTPU Indicator set.  This is done
      with the expectation that there will be an ACTPU subsequently
      sent over the CP-SVR pipe.

      However, if the PU is not defined as DLUR-supported at either
      the DLUS or the DLUR, it will not receive an ACTPU at all.  The
      processing logic should be modified to allow an ACTPU to sent
      over the TG if this situation is detected.

      The DLUS processing of the XID3 will changed to the following:

        When a DLUS receives an XID3 with the ACTPU Suppression
        Indicator reset, it will check the DLUR ACTPU Indicator:

          - if the DLUR ACTPU Indicator is reset, the DLUS will go ahead
            and send an ACTPU over the TG;

          - if the DLUR ACTPU Indicator is set, the DLUS will search its
            definitions for a DLUR-supported PU matching the PU for
            which the XID3 is being sent:

              * if a definition is found, the DLUS will not send an
                ACTPU over the TG - subsequent pipe activation
                mechanisms will cause an ACTPU to be sent over the
                CP-SVR pipe;

              * if no definition is found, the DLUS will send an ACTPU
                over the TG.

** 2) added DLUS-served LU registration

      The document currently requires an EN DLUR to set the Search
      Status Indicator in CP Capabilities to prevent the NNS from
      deleting the directory entries of DLUR-serviced dependent LUs
      (specifically DLUS-served LUs).

      This negates the usefulness of the Search Status Indicator for
      non-DLUS-served LUs.  A mechanism needs to be devised such that
      the Search Status Indicator may be turned off yet DLUS-served
      LUs not be deleted from the directory.

      This new mechanism, DLUS-served LU registration, impacts both the
      EN DLUR (incorporated into the base DLUR architecture) and its
      NNS (incorporated into new option set 1116).  The DLUR will
      handle the cases when its NNS supports or does not support the
      option set.

      The DLUR impacts are:

         * A DLUR-capable End Node must set the Search Status Indicator
           in the ENCP Search Control CV (X'33') during the CP
           Capabilities exchange with its network node server when the
           EN has full multi-subnet support but its NNS does not
           support DLUS-served LU registration.

         * When an EN DLUR has full multi-subnet support and its NNS
           supports DLUS-served LU registration, the Search Status
           Indicator can be reset and the DLUS-served LUs can be
           registered with the NNS.

         * When an EN DLUR has limited multi-subnet support, the
           Search Status Indicator can be reset and the DLUS-served
           LUs need not be registered with the NNS.

      A NN supporting DLUS-served LU registration (option set 1116):

         * will set the DLUS-served LU registration indicator in
           format 3 of the XID I-field

         * will mark resources being registered as DLUS-served LUs

         * when the corresponding EN DLUR's Search Status indicator is
           reset,

             - and when receiving a Locate with the OCR bit off for a
               registered DLUS-served LU,

                  will not forward the Locate

                  will not delete the registered resource from
                  the directory

                  will handle the Locate as if it had received a
                  negative reply to it from the DLUR

             - and when receiving a Locate with the OCR bit on for a
               registered DLUS-served LU,

                  will forward the Locate

                  will delete/retain the registered resource pending the
                  results in the Locate reply

         * when the corresponding EN DLUR's Search Status indicator
           is set,

             - and when receiving a Locate with the OCR bit off for a
               registered DLUS-served LU,

                  will forward the Locate

                  will not delete the registered resource from the
                  directory

             - and when receiving a Locate with the OCR bit on for a
               registered DLUS-served LU,

                  will forward the Locate

                  will delete/retain the registered resource pending the
                  results in the Locate reply

** 3) clarified description of X'8019 000C' sense code

      The current description of the X'8019 000C' indicates a Border
      Node is not in the PLU's subnet.  Actually, the sense code will
      be issued when an Extended Border Node is not in the PLU's
      subnet, or in fact any other subnet on the path between the DLUS
      and the PLU.

      The sense code description for X'8019 000C' will be changed to:

         Upon receiving a Locate request for a DLUS-served dependent LU,
         the DLUS node has determined that at least one intercluster
         link on the path between the DLUS and the PLU was not between
         two Extended Border Nodes.

** 4) added DLC signalling information formats for SDLC switched, V.25
      switched physical interface, and V.25bis switched physical
      interface

** 5) updated network management chapter:

         - changed the SNMP MIB:

             * deleted following managed objects from
               dlurNodeCapabilities group:

                    dlurImplementationType
                    dlurTDUsupport

             * in dlurPuEntry, deleted following managed object:

                    dlurPuActiveDlusIndex

             * in dlurDlusEntry, deleted following managed objects:

                    dlurDlusFRSNsent
                    dlurDlusFRSNreceived
                    dlurDlusTDUsupport
                    dlurDlusANSsupport
                    dlurDlusMultiSubnetSupport

           (a flat text version of the SNMP MIB is available via
           anonymous FTP from <networking.cary.ibm.com or
           ibmstandards.cary.ibm.com>; the file is
           </pub/standards/aiw/snasnmp/dlurmib.txt>)

         - changed the SNA/MS Alert section, defining five SNA/MS
           generic alerts to cover the error situations described in
           the previous edition

             The alerts are described using the tabular convention in
             the SNA/MS Reference book.

             These alerts contain several new alert code points that
             have been assigned by the alert code point registrar
             ([email-masked]), so these will not be found in
             the current SNA Formats book.  Please contact Mike Allen
             ([email-masked]) if you have questions about these
             alerts.  If you are unfamiliar with SNA/MS alerts, a good
             source to start with is the Alert Implementation Guide,
             which is on the current edition of the "Best of APPC and
             APPN" CD-ROM.  That book is a little out of date, but is
             still an excellent introduction to alerts.

** 6) made SF X'92' (Port Identifier) required for the Frame Relay PVC
      DLC signalling information format

      Christine Martin of Data Connection asked this morning whether
      the Port Identifier subfield was optional for SDLC non-switched,
      as it was for other DLC types.

      I passed the question on to Jim Ragsdale, not expecting his answer
      to alter the book I was nearly finished building; however, he
      proposed the following change which was included:

             The reason that the Port Identifier was deemed optional
             for TR and Ethernet, is that the port can be uniquely
             identified by the addresses (Source MAC address in case of
             LANs).  The Frame Relay case may have been a mistake now
             that I think about it.  Since Frame Relay DLCIs are only
             locally significant (meaning only unique to a given network
             provider interface) then the DLCI alone may not be
             sufficient to identify the port if more than one port is
             used for Frame Relay.  I think that we should probably
             make it mandatory.

             As for SDLC, one definitely cannot identify the port by
             the SDLC address, in fact the address may not even be the
             local node's address (the address being always the
             secondary's address).  Therefore the Port Identifier is
             required.  It is also required to reference the physical
             Interface information to the SDLC layer 2 information.

** 7) editorial changes - not marked with change bars

      a) (5.6.2.2.4, step 9) changed X'088E 0008' to X'088E 0009'

      b) (figure 5-14, step 5; figure 5-15, step 5; figure 5-20, step 7)
         changed "that its SSCP-PU session with PU2 is broken"
         to "that its SSCP-PU session with PU2 should be deactivated"

      c) (6.1.3.2) changed "LFSIDs for THa are independently ..." to
                           "LFSIDs for THb are independently ..."

      d) (figure 6-6, step 13; figure 6-7, step 9) changed SSCP1 to
         SSCP2

      e) (figure 7-1, steps 7, 11, 15; figure 9-1, step 3) changed
         SSCP-LU session identifier to FQPCID

      f) (section 8.1.4) added the following comment to the adaptive
         session pacing processing:

             (note that the supported/not supported settings are
             defined opposite to each other in the BIND and in the
             CV X'30')

      g) (figure 9-3, step 2) changed "is the CP(SLU)" to "is the
         NNS(CP(SLU))"

      h) (figure 9-5, step 17) changed BFSESSST to BFSESSEND

      i) (figure 11-2, step 4) changed NETA to NETB

      j) (13.1.6) added SDLC non-switched to the list of defined DLC
         types

      k) (D.1.18.1.6) For DLC type=SDLCNS, byte 2, bits 1-2, added the
         following definition of character transparency type:

                           11   Reserved

I'm requesting comments on these items to be received no later than
June 29.  If there is a consensus for approval at that time, I will
consider the document (and all related items which had previously
been granted AD and/or AP status) to be at CP status as of June 29
(at the AIW5 DLUR SIG session).

I put in a version number of 1.0 so that small changes (like fixes,
additional signalling information) can be tracked by version 1.1, 1.2,
etc., and major enhancements can be tracked as version 2.0, 3.0, etc.

I've also cleaned up the pub/standards/aiw/dlur directory, removing
all of the pre-AP drafts of the DLUR architecture document.

Bring your own copy of the CP draft to the SIG session; we won't be
including a copy in every binder.  As in the past, I'll entertain (and
be entertained by) special requests for me to bring a copy to the SIG
session for you.

Ed Tremblay